IBIS Macromodel Task Group

Meeting date: 30 March 2021

Members (asterisk for those attending):
Achronix Semiconductor      * Hansel Dsilva
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:     * Ambrish Varma
                              Ken Willis
                              Jared James
Google:                       Zhiping Yang
Intel:                      * Michael Mirmak
                              Kinger Cai
                              Alaeddin Aydiner
Keysight Technologies:      * Fangyi Rao
                              Radek Biernacki
                              Ming Yan
                              Todd Bermensolo
                              Rui Yang
Luminous Computing            David Banas
Marvell                       Steve Parker
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
Missouri S&T                  Chulsoon Hwang
Siemens EDA (Mentor):       * Arpad Muranyi
SiSoft (Mathworks):         * Walter Katz
                              Mike LaBonte
Teraspeed Labs:             * Bob Ross
Zuken USA:                    Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:
  
- Fangyi said he had a new presentation "Summary of BIRD210 Flow".
- Walter noted that he had sent out a PAMn BIRD draft and another BIRD draft
  explaining the technique of passing a unit impulse response in as a crosstalk
  column to get the model to return its equalization's response.

-------------
Review of ARs:

- Walter to submit his BIRD211.
  - Done.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the March 23rd
meeting.  Curtis noted two minor corrections:
1. Justin Butterfield had taken the minutes.
2. In the second sentence of the fourth paragraph of the BIRD210 discussion,
   this phrase:
     "...additional column for the unit impulse response is not modified."
   should be:
     "...additional column for the downstream impulse response is not modified."
Walter agreed.  With these two changes, Walter moved to approve the minutes.
Curtis seconded the motion.  There were no objections.

Curtis said he would send out an amended version, so the corrections should
appear in the version posted to the ATM minutes archives.

-------------
New Discussion:

Redriver Flow Issues:
Fangyi shared his new "Summary of BIRD210 Flow" presentation.

- slide 2 - Current Flow
This slide depicts the current IBIS 7.0 flow and introduces a block diagram
style depicting the input and output IRs of the various Tx and Rx Init
functions.

- slide 3 - Current Flow continued...
This slide lists what is shown in slide 2 for Init inputs.  It also makes
particular note of two things the legacy flow enabled: the Tx Init can optimize
based on its downstream channel, and the Rx Init can optimize based on its
upstream channel and crosstalk.

- slide 4 - BIRD210 Flow
This slide depicts the BIRD210 flow using the block diagram style from slide 2.
The white boxes represent the legacy flow of information, which is entirely
preserved in BIRD210.  The blue boxes represent the two new additional columns.
The empty blue boxes indicate place holder columns as inputs (the EDA tool does
not put anything in these columns, and the model returns something in them).

slide 5 - BIRD 210 Flow continued...
The first new column provides the cumulative upstream IR as an input to all the
Tx and Rx Init functions.  The second new column is used by the models to return
their equalization's response.  The terminal Rx returns cumulative IR for the
entire channel, including its own LTI and DFE effects.  The terminal Rx returns
the LTI portion of its equalization in the second new column.

This slide notes that the Tx Init under BIRD210 can optimize based on its
downstream, upstream, or both.  The Rx Init can optimize based on its upstream
response and crosstalk.

slide 7 - Statistical Simulation with Crosstalk
This slide depicts the flow of various crosstalk combinations.  It notes that
the BIRD210 flow provides the EDA tool with all the individual sections' through
and crosstalk responses, so the EDA tool can construct all possible crosstalk
paths.

slide 8 - Summary
This slide summarizes the benefits of BIRD210 and highlights some differences
between it and BIRD211.  The information in legacy columns of the impulse matrix
is unchanged, and new columns are added for the new information.  So legacy
models, including any Tx that optimizes based on its downstream channel, still
work.  Rx models that optimize based on crosstalk won't have to deduce whether
one of the crosstalk columns actually contains a unit IR passed in by the EDA
tool for the purpose of getting the model's equalization response back.

Bob said he was wrestling with the choice between BIRD210 and BIRD211.  He asked
if there were any technical objections to BIRD210 or any reasons why it can't
work as presented.

Walter offered comments on slide 4, the BIRD210 flow.  He offered an example
scenario in which he had a primary Tx that's a dual model and works fine,
a redriver Rx that works fine and follows the white boxes (legacy portion) of
Fangyi's flow chart, a redriver Tx that doesn't optimize itself and just takes
the output of the redriver Rx and modifies it and sends it to the downstream
channel, and finally a terminal Rx that has DFE and optimization.  He said
device vendors have been providing him with these types of models all along,
and they just work with his BIRD211 redriver flow.  With BIRD210, however, these
models just don't work.  All 4 models would have to be rewritten to handle the
two additional columns shown in blue, but none of the extra information in blue
is necessary in the most common cases when the redriver Tx does not optimize
based on the downstream channel and the terminal Rx does not change its
equalization based on the crosstalk input.  Since all the models we currently
have "on the shelf" today don't need the blue columns, why not just adopt
BIRD211 and make them all work simply by changing the flow so that the output of
Rx1 is included in what is passed into Rx2 instead of being added to the output
of Rx2?  Walter said BIRD211 works with every model that is out there.

Fangyi said BIRD210 is designed to be consistent with the legacy flow and not
change anything for legacy models.  A legacy model wouldn't even know about the
two new columns.  Walter said the problem is that the legacy flow for redrivers
is completely broken, and if a model doesn't have access to the new columns in
the BIRD210 flow then it doesn't work at all.  With BIRD210 if you have an old
model the flow is broken.  Ambrish again emphasized that we are only talking
about the redriver "statistical flow" as having a problem the requires fixing.

Fangyi said both proposals have cases they correct and cases they will break.
He said Walter's BIRD211 will break if the redriver Tx optimizes based on the
downstream channel, and it will also break if the Rx model optimizes based on
crosstalk aggressors.  Walter did not agree with these statements.

Walter shared his BIRD211.  He reviewed the flow diagrams in the Definition of
the Issue section and noted that we all agree that the existing flow is
fundamentally broken because the terminal Rx's Init function does not see
everything upstream.  The flow diagram for the common case in BIRD211 includes
the Rx1 output in the input to Tx2, though Walter noted that this is equivalent
to what BIRD166 proposed, where the output of Rx1 was combined with the output
of Tx2 and passed to Rx2, for the common cases where the Tx2 does not optimize
and is entirely LTI.  Walter noted that the co-author of BIRD166 was an IC
vendor.

Walter said his BIRD only adds the new parameter for the Tx2, and only in the
special case where the Tx2 optimizes based on the downstream channel.  He agreed
this case had not been handled by BIRD166, and said Fangyi's concern about
BIRD166 had been legitimate.  But with BIRD211 the Tx2 gets the upstream info it
needs to optimize and avoid saturation, and with the new parameter it can also
specify that it needs the downstream channel response so it can handle some
effects optical channels care about.  He said such optical channel models are
currently being developed and not already distributed.  Walter said any legacy
electrical channel Tx2 model that optimizes based on the downstream channel
would have to be rewritten, but he was only aware of one that ever did that, and
it is now likely obsolete.

Walter then addressed potential issues with crosstalk.  He said that with his
BIRD211 flow the Rx2 gets all the aggressing crosstalk information.  He noted
that if all the models are Dual models, then we would never need to know the
impulse response of the equalization from Init, and we would never have to
worry about deconvolution to figure it out.   In terms of Init processing, the
Rx2 gets all the crosstalk information it needs.  If the Rx2 is doing anything
with crosstalk then it needs all the upstream models to have
Init_Returns_Impulse = True, because it would need all the upstream information
in Init because there is no crosstalk modification in GetWave.  Walter said
there are two reasons an Rx model looks at crosstalk.  One is crosstalk
cancellation, in which case an Rx typically worries about crosstalk from
adjacent signal lines and puts them through processing to cancel the crosstalk.
He said this requires the EDA tool or user to tell the model which of the
crosstalk columns in the impulse matrix are the ones to be cancelled.   He said
the potential gains from this type of processing are dramatic, but it only works
for FEXT and is disaster for NEXT.  Walter said the other use of crosstalk by an
Rx model would be to optimize and make tradeoffs between CTLE, DFE, FFE, etc.
He said anyone writing a model that sophisticated would not be doing an Init
Only model.  If it's doing all that sophisticated stuff, then it would have to
have a GetWave anyway.

Fangyi said Walter was making assumptions, and that one of the purposes of the
second new column in BIRD210 was to provide the filter's response so the tool
can make a proxy GetWave for an Init Only model.  Walter said any model maker
smart enough to write a model optimizing based on crosstalk would provide a
GetWave.  So, there would be no need for the EDA tool to determine the response
of the filter from the Init processing, and no need to worry about confusing the
model by passing in a unit IR in a crosstalk column for the purpose of
determining the equalization's response.  He said if we really want to make a
special case for a crosstalk optimizing model maker that is too lazy to add a
GetWave and doesn't make their model smart enough to ignore a unit IR passed in
via a crosstalk column, then he thought we should take that up in a separate
BIRD.  Fangyi said his BIRD already handles such cases and makes no assumptions.
Walter said that model makers won't want to be burdened by BIRD210 changes when
they're only needed for very specific cases, and as an EDA vendor he did not
want to deal with extra columns in cases where it's unnecessary.

Walter said there are two purposes for a BIRD.  One is to let EDA tools know how
to run the simulations, the other is to tell model makers how to make their
models.  He said as long as the model maker isn't doing anything special, his
standard BIRD211 flow works fine.  The exception might be a legacy Tx2 that
optimized based on its downstream, but the existing flow is completely broken
for that case too.  He said any EDA vendors are already using a flow similar to
BIRD211 for their redriver simulations, or they're getting terribly wrong
answers.

PAMn BIRD:
Walter said he'd sent out a draft of a PAMn BIRD.  He said they had an internal
debate about whether to write a PAM3 BIRD or a more general PAMn BIRD.  He said
he'd decided to do a more general BIRD, so the levels are in a table instead of
introducing new PAM3_... threshold parameters.

Arpad and Fangyi said they thought there were problems with addressing the
different ways data could be encoded for the same PAMn.  Walter asked everyone
to read the BIRD draft and be ready to discuss it next time.

- Ambrish: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

AR: Curtis to send out amended minutes from the previous meeting.

-------------
Next meeting: 06 April 2021 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
